Methods and Related Devices for Implementing Disaster Recovery

ABSTRACT

Provided are methods and related devices for implementing disaster recovery. According to a method, in a case where a main Session Management Function (SMF) fails, a backup SMF sends a first request to a User Plane Function (UPF), wherein the first request carries a node identifier (Node ID) of the main SMF, a Node ID of the backup SMF, and a Common Session endpoint Identifier List (CSIDLIST) corresponding to the backup SMF; and the first request is used for notifying the UPF that the main SMF fails and a session or sessions in the CSIDLIST corresponding to the backup SMF is/are to be taken over by the backup SMF, so that the UPF subsequently interacts with the backup SMF for the session or sessions in the CSIDLIST corresponding to the backup SMF.

CROSS REFERENCE

This application is a National Stage Filing of the PCT InternationalApplication No. PCT/CN2019/119193 filed on Nov. 18, 2019, which claimspriority to the Chinese Application No. 201811415354.7 filed on Nov. 23,2018, the entirety of which is herein incorporated by reference.

TECHNICAL FIELD

Embodiments of the present disclosure relate to, but are not limited to,a disaster recovery technology, and more particularly to methods andrelated devices for implementing disaster recovery.

BACKGROUND

In the control plane/user plane (CU, where C represents Control plane,and U represents User plane) separation architecture, a SessionManagement Function (SMF) of a Control Plane (CP) and a User PlaneFunction (UPF) of a User Plane (UP) perform message communicationthrough a CUPS (Control and User Plane Separation of EPC nodes) protocolof an N4 interface. According to an application type of a PacketForwarding Control Protocol (PFCP) interface message, the message can bedivided into a node-type message and a session-type message. Thenode-type message is mainly used for coupling, heartbeat detection andthe like between C and U, and the session-type message is used forsession establishment, modification, release and the like between theSMF and the UPF.

In a conventional art, in a case where an SMF is down due to a failure,the UPF cannot acquire information of a backup SMF and the originalsession information, thereby resulting in session release, which affectsuser experience.

SUMMARY

In view of the above, an embodiment of the present disclosure provides amethod for implementing disaster recovery, including the followingoperations.

In a case where a main SMF fails, a backup SMF sends a first request toa UPF, wherein the first request carries a Node ID of the main SMF, aNode ID of the backup SMF and a Common Session endpoint Identifier List(CSIDLIST) corresponding to the backup SMF, and the first request isused for notifying the UPF that the main SMF fails and a session orsessions in the CSIDLIST corresponding to the backup SMF is/are to betaken over by the backup SMF, so that the UPF subsequently interactswith the backup SMF for the session or sessions in the CSIDLISTcorresponding to the backup SMF.

In view of the above, an embodiment of the present disclosure provides amethod for implementing disaster recovery, including the followingoperations.

A UPF receives a first request sent by a backup SMF, wherein the firstrequest carries a Node ID of a main SMF, a Node ID of the backup SMF,and a CSIDLIST corresponding to the backup SMF, and the first request isused for notifying the UPF that the main SMF fails and a session orsessions in the CSIDLIST corresponding to the backup SMF is/are to betaken over by the backup SMF.

The UPF records a correspondence table between the main SMF and thebackup SMF according to the first request, and subsequently interactswith the backup SMF for the session or sessions in the CSIDLISTcorresponding to the backup SMF, wherein the correspondence tableincludes a state of the main SMF, the backup SMF corresponding to themain SMF, and the CSIDLIST corresponding to the backup SMF.

In view of the above, an embodiment of the present disclosure provides amethod for implementing disaster recovery, including the followingoperations.

In a case where a backup SMF has taken over a CSIDLIST corresponding tothe backup SMF and a main SMF recovers from a failure, the main SMFsends a third request to a UPF, wherein the third request carries a NodeID of the main SMF, a Node ID of the backup SMF, and a CSIDLISTcorresponding to the main SMF, and the third request is used fornotifying the UPF that the main SMF recovers from the failure and that asession or sessions in the CSIDLIST corresponding to the main SMF is/areto be taken over by the main SMF, so that the UPF subsequently interactswith the main SMF for the session or sessions in the CSIDLISTcorresponding to the main SMF.

In view of the above, an embodiment of the present disclosure provides amethod for implementing disaster recovery, including the followingoperations.

A UPF receives a third request sent by a main SMF, wherein the thirdrequest carries a Node ID of the main SMF, a Node ID of a backup SMF,and a CSIDLIST corresponding to the main SMF, and the third request isused for notifying the UPF that the main SMF recovers from a failure anda session or sessions in the CSIDLIST corresponding to the main SMFis/are to be taken over by the main SMF.

The UPF sets a state of the main SMF in a stored correspondence tablebetween the main SMF and the backup SMF to normal according to the thirdrequest, and subsequently interacts with the main SMF for the session orsessions in the CSIDLIST corresponding to the main SMF, wherein thecorrespondence table includes the state of the main SMF, the backup SMFcorresponding to the main SMF, and the CSIDLIST corresponding to thebackup SMF.

In view of the above, an embodiment of the present disclosure provides abackup SMF, including:

a sending unit, configured to send a first request to a UPF in a casewhere a main SMF fails, wherein the first request carries a Node ID ofthe main SMF, a Node ID of the backup SMF and a CSIDLIST correspondingto the backup SMF, and the first request is used for notifying the UPFthat the main SMF fails and a session or sessions in the CSIDLISTcorresponding to the backup SMF is/are to be taken over by the backupSMF, so that the UPF subsequently interacts with the backup SMF for thesession or sessions in the CSIDLIST corresponding to the backup SMF.

In view of the above, an embodiment of the present disclosure provides aUPF, including:

a receiving unit, configured to receive a first request sent by a backupSMF, wherein the first request carries a Node ID of a main SMF, a NodeID of the backup SMF, and a CSIDLIST corresponding to the backup SMF,and the first request is used for notifying the UPF that the main SMFfails and a session or sessions in the CSIDLIST corresponding to thebackup SMF is/are to be taken over by the backup SMF; and

a processing unit, configured to record a correspondence table betweenthe main SMF and the backup SMF according to the first request, andsubsequently interact with the backup SMF for the session or sessions inthe CSIDLIST corresponding to the backup SMF, wherein the correspondencetable includes a state of the main SMF, the backup SMF corresponding tothe main SMF, and the CSIDLIST corresponding to the backup SMF.

In view of the above, an embodiment of the present disclosure provides amain SMF, including:

a sending unit, configured to send a third request to a UPF in a casewhere a backup SMF has taken over a session or sessions in a CSIDLISTcorresponding to the backup SMF and the main SMF recovers from afailure, wherein the third request carries a Node ID of the main SMF, aNode ID of the backup SMF, and a CSIDLIST corresponding to the main SMF,and the third request is used for notifying the UPF that the main SMFrecovers from the failure and that a session or sessions in the CSIDLISTcorresponding to the main SMF is/are to be taken over by the main SMF,so that the UPF subsequently interacts with the main SMF for the sessionor sessions in the CSIDLIST corresponding to the main SMF.

In view of the above, an embodiment of the present disclosure provides aUPF, including:

a receiving unit, configured to receive a third request sent by a mainSMF, wherein the third request carries a Node ID of the main SMF, a NodeID of a backup SMF, and a CSIDLIST corresponding to the main SMF, andthe third request is used for notifying the UPF that the main SMFrecovers from a failure and a session or sessions in the CSIDLISTcorresponding to the main SMF is/are to be taken over by the main SMF;and

a processing unit, configured to set a state of the main SMF in a storedcorrespondence table between the main SMF and the backup SMF to normalaccording to the third request, and to subsequently interact with themain SMF for the session or sessions in the CSIDLIST corresponding tothe main SMF, wherein the correspondence table includes the state of themain SMF, the backup SMF corresponding to the main SMF, and the CSIDLISTcorresponding to the backup SMF.

In view of the above, an embodiment of the present disclosure provides abackup SMF, including a memory, a processor, and a computer programstored in the memory and capable of running on the processor. Thecomputer program, when executed by the processor, performs the methodfor implementing the disaster recovery executed by the backup SMF.

In view of the above, an embodiment of the present disclosure provides amain SMF, including a memory, a processor and a computer program storedin the memory and capable of running on the processor. The computerprogram, when executed by the processor, performs the method forimplementing the disaster recovery executed by the main SMF.

In view of the above, an embodiment of the present disclosure provides aUPF, including a memory, a processor, and a computer program stored inthe memory and capable of running on the processor. The computerprogram, when executed by the processor, performs any method forimplementing the disaster recovery executed by the UPF.

In view of the above, an embodiment of the present disclosure provides acomputer readable storage medium. The computer readable storage mediumstores an information processing program, and when the informationprocessing program is executed by a processor, the operations ofimplementing disaster recovery as described in any one of the foregoingembodiments are implemented.

In view of the above, an embodiment of the present disclosure provides asystem for implementing disaster recovery, including any one of thebackup SMFs, any one of the main SMFs, and any one of the UPFs.

Compared with the conventional art, the embodiments of the presentdisclosure provide methods and related devices for implementing disasterrecovery. According to one of the methods, in a case where a main SMFfails, a backup SMF sends a first request to a UPF, wherein the firstrequest carries a Node ID of the main SMF, a Node ID of the backup SMFand a CSIDLIST corresponding to the backup SMF, and the first request isused for notifying the UPF that the main SMF fails and a session orsessions in the CSIDLIST corresponding to the backup SMF is/are to betaken over by the backup SMF, so that the UPF subsequently interactswith the backup SMF for the session or sessions in the CSIDLISTcorresponding to the backup SMF. In this way, in a case where the mainSMF fails, the UPF can identify the failed main SMF and acquire thebackup SMF and the original session information, so as to implementbatch session migration and ensure session continuity.

Additional features and advantages of the embodiments of the disclosurewill be set forth in the description that follows, and in part will beobvious from the description, or may be learned by implementation of theembodiments of the disclosure. The objects and other advantages of theembodiments of the disclosure may be realized and attained by thestructure provided in the description, claims and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings described herein are used to provide a deeperunderstanding of the present disclosure, and constitute a part of thepresent application. The drawings and the exemplary embodiments of thepresent disclosure are used to explain the present disclosure. Thedrawings and the exemplary embodiment do not constitute limitations tothe present disclosure.

FIG. 1 is a schematic flowchart of a method for implementing disasterrecovery according to a first embodiment of the present disclosure;

FIG. 2 is a schematic flowchart of a method for implementing disasterrecovery according to a second embodiment of the present disclosure;

FIG. 3 is a schematic diagram of an extended PFCP interface messageaccording to a third embodiment of the present disclosure;

FIG. 4 is a schematic diagram of parameters in a Session SetModification Request according to a third embodiment of the presentdisclosure;

FIG. 5 is a schematic diagram of parameters in a Session SetModification Response according to a third embodiment of the presentdisclosure;

FIG. 6 is a schematic flowchart of a method for implementing disasterrecovery according to a fourth embodiment of the present disclosure;

FIG. 7 is a schematic flowchart of a method for implementing disasterrecovery according to a fifth embodiment of the present disclosure;

FIG. 8 is a schematic flowchart of a method for implementing disasterrecovery according to a sixth embodiment of the present disclosure;

FIG. 9 is a schematic flowchart of a method for implementing disasterrecovery according to a seventh embodiment of the present disclosure;

FIG. 10 is a schematic flowchart of a method for implementing disasterrecovery according to an eighth embodiment of the present disclosure;

FIG. 11 is a schematic flowchart of a method for implementing disasterrecovery according to a ninth embodiment of the present disclosure;

FIG. 12 is a schematic structural diagram of a backup SMF according toan embodiment of the present disclosure;

FIG. 13 is a schematic structural diagram of a UPF according to anembodiment of the present disclosure;

FIG. 14 is a schematic structural diagram of a main SMF according to anembodiment of the present disclosure; and

FIG. 15 is a schematic structural diagram of another UPF according to anembodiment of the present disclosure.

DETAILED DESCRIPTION OF THE EMBODIMENTS

To make the objectives, technical solutions, and advantages of theembodiments of the present disclosure clearer and more comprehensible,the embodiments of the present disclosure will be described in detailwith reference to the accompanying drawings. It is important to notethat the embodiments in the present application and characteristics inthe embodiments may be combined to derive other embodiments notexplicitly described.

Operations shown in the flowchart of the drawings may be performed in acomputer system such as a set of computer executable instructions.Furthermore, although a logic sequence is shown in the flowchart, insome cases, the shown or described operations may be executed in asequence different from that shown in the flowchart.

In the current CU separation architecture, in a case where a main SMF isdown due to failure, the session or sessions undertaken by the main SMFcan be processed by a backup SMF of the main SMF through sessionmigration. However, in a case where the main SMF fails, the UPF cannotacquire the backup SMF and the original session information via existingmessages, which easily leads to session release and affects the userexperience.

In this regard, the embodiments of the present disclosure providetechnical solutions for implementing disaster recovery. In a case wherean SMF is down due to failure, a backup SMF can perform batch sessionmigration to implement load sharing while keeping an original session ororiginal sessions uninterrupted. Meanwhile, compared with the manner ofmigrating sessions one by one, the total amount of messages required canbe effectively reduced, and network congestion is avoided.

The technical solutions provided by the embodiments of the presentdisclosure are described in detail below through several exemplaryembodiments.

First Embodiment

FIG. 1 is a schematic flowchart of a method for implementing disasterrecovery according to a first embodiment of the present disclosure. Asshown in FIG. 1, the method includes an operation 101.

In operation 101, in a case where a main SMF fails, a backup SMF sends afirst request to a UPF.

According to the embodiment, the first request carries a Node ID of themain SMF, a Node ID of the backup SMF and a CSIDLIST corresponding tothe backup SMF. The first request is used for notifying the UPF that themain SMF fails and a session or sessions in the CSIDLIST correspondingto the backup SMF is/are to be taken over by the backup SMF, so that theUPF subsequently interacts with the backup SMF for the session orsessions in the CSIDLIST corresponding to the backup SMF.

After the backup SMF sends the first request to the UPF, the method mayfurther include the following operation.

The backup SMF receives a first response to the first request from theUPF.

According to some exemplary implementation of the embodiment, the firstresponse to the first request carries the Node ID of the backup SMF. Thefirst response to the first request is used for notifying the backup SMFthat the UPF accepts or rejects the first request.

Before the backup SMF sends the first request to the UPF, the method mayfurther include the following operations.

The backup SMF receives a notification message sent by a NetworkFunction Repository Function (NRF).

According to some exemplary implementation of the embodiment, thenotification message carries the Node ID of the main SMF, the Node ID ofthe backup SMF, and the CSIDLIST corresponding to the backup SMF. Thenotification message is used for notifying the backup SMF that the mainSMF fails and the backup SMF takes over the session or sessions in theCSIDLIST corresponding to the backup SMF.

The backup SMF acquires, through an Unstructured Data Storage Function(UDSF), address information of the UPF that has established at least onesession with the main SMF.

After the backup SMF sends the first request to the UPF or after thebackup SMF receives the first response for accepting the first requestfrom the UPF, the method may further include the following operation.

The backup SMF acquires context of the session or sessions in theCSIDLIST corresponding to the backup SMF from an UDSF.

After the backup SMF acquires the context of the session or sessions inthe CSIDLIST corresponding to the backup SMF from the UDSF, the methodmay further include the following operation.

The backup SMF sends a second request to the UPF.

According to some exemplary implementation of the embodiment, the secondrequest carries a Control Plane (CP) Fully Qualified Session EndpointIdentifier (F-SEID) acquired from the context, an Internet Protocol (IP)address in the CP F-SEID being updated to an IP address of the backupSMF. The second request is used for notifying the UPF to record theupdated CP F-SEID for the session or sessions in the CSIDLIST, and set amigration flag for the session or sessions in the CSIDLIST, wherein themigration flag is used for identifying the corresponding session orsessions as migrated session or sessions.

After the backup SMF sends the second request to the UPF, the method mayfurther include the following operation.

The backup SMF receives a second response to the second request from theUPF. According to some exemplary implementation of the embodiment, thesecond response to the second request carries a Node ID of the backupSMF. The second response to the second request is used for notifying thebackup SMF that the UPF accepts or rejects the second request.

Before the backup SMF receives the notification message sent by the NRF,the method may further include the following operation.

The main SMF having established at least one session with the UPFregisters a main-backup relation on the NRF, and sets the CSIDLISTcorresponding to the backup SMF.

According to some exemplary implementation of the embodiment, the firstrequest is an extended Packet Forwarding Control Protocol node-typemessage Session Set Modification Request (PFCP Session Set ModificationRequest).

According to some exemplary implementation of the embodiment, the firstresponse to the first request is an extended Packet Forwarding ControlProtocol node-type message Session Set Modification Response (PFCPSession Set Modification Response).

Second Embodiment

FIG. 2 is a schematic flowchart of a method for implementing disasterrecovery according to a second embodiment of the present disclosure. Asshown in FIG. 2, the method includes operations 201 and 202.

In operation 201, a UPF receives a first request sent by a backup SMF.

According to the embodiment, the first request carries a Node ID of amain SMF, a Node ID of the backup SMF, and a CSIDLIST corresponding tothe backup SMF. The first request is used for notifying the UPF that themain SMF fails and a session or sessions in the CSIDLIST correspondingto the backup SMF is/are to be taken over by the backup SMF.

In operation 202, the UPF records a correspondence table between themain SMF and the backup SMF according to the first request, andsubsequently interacts with the backup SMF for the session or sessionsin the CSIDLIST corresponding to the backup SMF.

According to the embodiment, the correspondence table includes a stateof the main SMF, the backup SMF corresponding to the main SMF, and theCSIDLIST corresponding to the backup SMF.

After the UPF receives the first request sent by the backup SMF, themethod may further include the following operation.

The UPF sends a first response to the first request to the SMF.

According to some exemplary implementation of the embodiment, the firstresponse to the first request carries the Node ID of the backup SMF. Thefirst response to the first request is used for notifying the backup SMFthat the UPF accepts or rejects the first request.

In a case determining, according to a condition of the UPF, that the UPFis capable of recording the correspondence table between the main SMFand the backup SMF, the UPF sends the first response for accepting thefirst request to the SMF.

In a case determining, according to a condition of the UPF, that the UPFis not capable of recording the correspondence table between the mainSMF and the backup SMF, the UPF sends the first response for rejectingthe first request to the SMF.

After the UPF records the correspondence table between the main SMF andthe backup SMF according to the first request, or after the UPF sendsthe first response for accepting the first request to the SMF, themethod may further include the following operations.

The UPF receives a second request sent by the backup SMF.

According to some exemplary implementation of the embodiment, the secondrequest carries a CP F-SEID, an IP address in the CP F-SEID beingupdated to an IP address of the backup SMF. The second request is usedfor notifying the UPF to record the updated CP F-SEID for the session orsessions in the CSIDLIST corresponding to the backup SMF, and set amigration flag for the session or sessions in the CSIDLIST correspondingto the backup SMF, wherein the migration flag is used for identifyingthe corresponding session or sessions as migrated session or sessions.

The UPF records the updated CP F-SEID for the session or sessions in theCSIDLIST corresponding to the backup SMF according to the secondrequest, and sets the migration flag for the session or sessions in theCSIDLIST in the correspondence table.

After the UPF receives the second request sent by the backup SMF, themethod may further include the following operation.

The UPF sends a second response to the second request to the backup SMF.

According to some exemplary implementation of the embodiment, the secondresponse to the second request carries the Node ID of the backup SMF.The second response to the second request is used for notifying thebackup SMF that the UPF accepts or rejects the second request.

The operation of subsequently interacting with the backup SMF for thesession or sessions in the CSIDLIST corresponding to the backup SMF maybe implemented in the following manner.

In a case where the UPF needs to send a message or messages related tothe session or sessions in the CSIDLIST corresponding to the backup SMF,the UPF acquires a state of the main SMF according to the correspondencetable.

The UPF sends the message or messages to the backup SMF in a case wherethe state of the main SMF indicates that the main SMF fails.

The technical solutions provided by the first embodiment and the secondembodiment of the present disclosure are elaborated below throughseveral exemplary embodiments.

Third Embodiment

In a case where a main SMF fails, in order to enable the UPF to acquirethe backup SMF and the original session information through PFCPinterface messages, this embodiment of the present disclosure extendsthe definition of the existing PFCP interface messages by introducingtwo new messages: a session set modification request (Session SetModification Request) and a session set modification response (SessionSet Modification Response), as shown in FIG. 3.

Parameters included in the Session Set Modification Request are shown inFIG. 4, and parameters included in the Session Set Modification Responseare shown in FIG. 5.

In a case where the main SMF fails, the backup SMF sends a Session SetModification Request to the UPF, notifying the UPF of the node ID of thefailed SMF and that the CSIDLIST is to be taken over by the backup SMF.The UPF records a mapping relationship between the failed SMF, theCSIDLIST taken over and the backup SMF. For example, a correspondencetable between the main SMF and the backup SMF is stored, and thecorrespondence table includes a state of the main SMF, the backup SMFcorresponding to the main SMF and the CSIDLIST corresponding to thebackup SMF. The UPF executes a session migration process. Then, the UPFsends a Session Set Modification Response to the backup SMF, andsubsequently interacts with the backup SMF for all sessions in the rangeof the CSIDLIST taken over.

A batch of sessions to be taken over by the backup SMF is defined as aCommon Session Endpoint Identifier (CSID) LIST (abbreviated asCSIDLIST). For example, a group of sessions having the same attribute orfeature may be defined as a CSIDLIST. These sessions may have continuousCSIDs or discontinuous CSIDs. Therefore, the session or sessions of thefailed SMF may be migrated to one or more backup SMFs in batches basedon the CSIDLIST.

Before the backup SMF sends the Session Set Modification Request to theUPF, in a case where an SMF is down due to a failure, an NF RepositoryFunction (NRF) sends a state notification to the backup SMF of the SMFto notify the backup SMF that the SMF has failed and notify the backupSMF of the CSIDLIST corresponding to the backup SMF. The Backup SMFrecords the failure information and takes over the session or sessionsof the failed SMF in the range identified by the CSIDLIST. Afterreceiving the state notification from the NRF, the backup SMF mayacquire the information of the UPF having established at least onesession with the main SMF from the UDSF. For example, the backup SMF mayacquire the address information of the UPF corresponding to the main SMFfrom the UDSF.

When being powered on, the main SMF registers a main-backup relation onthe NRF, and sets a CSIDLIST corresponding to the backup SMF for the NRFafter establishing at least one session with the UPF.

In a case where the main SMF recovers from a failure, the main SMF sendsa Session Set Modification Request to the UPF, and notifies the UPF ofthe Node ID of the backup SMF and that the CSIDLIST is to be taken overby the main SMF. Then, the UPF identifies that the state of the main SMFis recovered, sets the state of the main SMF to normal in thecorrespondence table recording the main SMF, the CSIDLIST and the backupSMF, and executes a session reverse flow. Then, the UPF sends a SessionSet Modification Response to the SMF, and subsequently interacts withthe main SMF for all sessions within the range of the CSIDLIST.

In a case where the main SMF recovers from a failure, before the mainSMF sends the Session Set Modification Request to the UPF, the main SMFacquires the Node ID of the backup SMF and the corresponding CSIDLISTfrom the NRF, and may also acquire the information of the UPF that hasestablished at least one session with the backup SMF, for example, theaddress information of the UPF corresponding to the backup SMF, from theUDSF.

In addition, the first request, the first response to the first request,the third request, and the third response to the third request mentionedin the first embodiment and the second embodiment of the presentdisclosure may be embodied as the extended Session Set ModificationRequest/extended Session Set Modification Response in the thirdembodiment in some exemplary implementations. It may be appreciated thatthe first request, the first response to the first request, the thirdrequest, and the third response to the third request mentioned in thefirst embodiment and the second embodiment may also adopt other similarfunctioned message interfaces between C and U.

The technical solution provided in the third embodiment of the presentdisclosure may be applied to 5^(th) Generation (5G) architecture or asimilar scenario in 4^(th) Generation (4G) architecture, and thereforehas strong practicability and universality.

Fourth Embodiment

The fourth embodiment is applicable to a scenario where the main SMFcorresponds to one backup SMF.

FIG. 6 is a schematic flowchart of a method for implementing disasterrecovery according to a fourth embodiment of the present disclosure. Asshown in FIG. 6, the method includes operations 601 to 610.

In operation 601, in a case where a main SMF fails, an NRF sends anotification message to a backup SMF to notify that the main SMF fails.

In the embodiment, the notification message is used for notifying thebackup SMF that the main SMF fails and that the backup SMF takes over asession or sessions in a CSIDLIST corresponding to the backup SMF.

In the embodiment, the notification message carries a Node ID of themain SMF, a Node ID of the backup SMF, and the CSIDLIST corresponding tothe backup SMF.

In some practical implementations, in a case where the main SMF isstarted up, the main SMF registers a main-backup relation on the NRF,and sets a CSIDLIST corresponding to the backup SMF according to thesession or sessions having been established between the main SMF and theUPF. After the main SMF fails, the NRF notifies the backup SMF of theSMF according to the main-backup relation previously registered by theSMF.

In operation 602, the backup SMF records the failure of the main SMFaccording to the notification message and identifies the correspondingtakeover session range CSIDLIST;

In operation 603, the backup SMF acquires the address information of theUPF that has established at least one session with the main SMF throughthe UDSF.

In the embodiment, the UDSF may be used to store and retrieveinformation of any network function (NF). The UDSF is a function in theconventional art and will not be described herein.

In operation 604, the backup SMF sends a Session Set ModificationRequest to the UPF.

In the embodiment, the Session Set Modification Request carries a NodeID of the backup SMF, a Node ID of the main SMF, and a CSIDLIST takenover. The Session Set Modification Request is used to notify the UPFthat the session or sessions in the CSIDLIST corresponding to the nodeidentified by this Node ID is/are to be taken over by the backup SMF.

In operation 605, the UPF identifies a failure of the main SMF accordingto the received Session Set Modification Request, and records acorrespondence table between the failed main SMF+ CSIDLIST and thebackup SMF.

In the embodiment, the correspondence table includes: the state of themain SMF (failed), the backup SMF corresponding to the main SMF, and theCSIDLIST taken over by the backup SMF.

In a case where the UPF receives the Session Set Modification Request,the operation 605 may be directly performed in normal cases. However, ifthe UPF is not able to process the Session Set Modification Request (forexample, a possible reason may be that the UPF is overloaded making itimpossible for the UPF to process the Session Set Modification Request),the UPF may directly send a Session Set Modification Response forrejecting the request to the backup SMF, and the session migrationfails.

In operation 606, the UPF sends a Session Set Modification Response ofaccepting the request to the backup SMF.

In the embodiment, the Session Set Modification Response is used fornotifying the backup SMF that the UPF accepts the Session SetModification Request.

In operation 607, the backup SMF acquires, from the UDSF, the context ofthe session or sessions in the CSIDLIST taken over.

In practical implementations, the backup SMF may acquire the context ofthe migrated session or sessions from the SMF tenant space of the UDSFafter receiving the Session Set Modification Response for accepting therequest, or in response to the usage amount report of the UPF or thetrigger of a CP NF.

In operation 608, the backup SMF sends a Session Modification Request tothe UPF.

In the embodiment, the Session Modification Request is an existing PFCPinterface message, and carries a Control Plane (CP) Fully QualifiedSession Endpoint Identifier (F-SEID), wherein the original session datain the SEID part of the CP F-SEID are kept unchanged, and the IP addressis updated to an IP address of the backup SMF. The Session ModificationRequest is used for notifying the UPF to modify the CP F-SEID of themigrated session or sessions.

In operation 609, the UPF records a new CP F-SEID according to thereceived Session Modification Request, and labels the session orsessions in the CSIDLIST taken over as having been migrated.

In the embodiment, in a case where the UPF receives the SessionModification Request, the operation 609 may be directly performed innormal cases. However, if the UPF is not able to process the SessionModification Request (for example, a possible reason may be that the UPFis overloaded making it impossible for the UPF to process the SessionSet Modification Request), the UPF may directly send a SessionModification Response for rejecting the request to the backup SMF, andthe update of the CP F-SEID fails.

In the embodiment, for the session or sessions set with a migrationflag, when sending a message subsequently, the UPF needs to acquire anactual state of the main SMF according to a correspondence between theSMF+CSIDLIST and the backup SMF, and send the message to the backup SMFin a case where the main SMF fails.

In operation 610, the UPF sends a Session Modification Response to thebackup SMF.

The Session Modification Response is also an existing PFCP interfacemessage. The Session Modification Response carries a Node ID of thebackup SMF, and is used for notifying the backup SMF that the UPFaccepts the Session Modification Request.

According to the technical solution provided in the fourth embodiment ofthe present disclosure, after a main SMF is down due to a failure, abackup SMF takes over a session or sessions within the range of theCSIDLIST of the failed SMF, and notifies, via sending a PFCP Session SetModification Request, a UPF to perform batch session migration; then,the backup SMF acquires context of the session or sessions of the mainSMF from a UDSF, and notifies, via sending a PFCP Session Modification,the UPF to update session information including a CP F-SEID, and tointeract with the backup SMF for the subsequent session or sessions. Inthis way, the messages such as the PFCP Session Set ModificationRequest/PFCP Session Set Modification Response are extended to implementbatch session migration and ensure session continuity.

Fifth Embodiment

The fifth embodiment is applicable to a scenario where the main SMFcorresponds to two backup SMFs.

FIG. 7 is a schematic flowchart of a method for implementing disasterrecovery provided by the fifth embodiment of the present disclosure. Asshown in FIG. 7, the method includes operations 701 to 718.

In operation 701, after a main SMF fails, an NRF notifies a backup SMF1of the SMF according to a main-backup relation registered by the mainSMF.

In operation 702, after receiving notification from the NRF, the backupSMF1 records a failure of the main SMF, and acquires a session rangeCSIDLIST1 to be taken over by the backup SMF1.

In the embodiment, the backup SMF1 may acquire address information ofthe UPF related to the session or sessions through the UDSF.

In operations 703-704, similar to the operations 701-702, the backupSMF2 starts taking over the session range CSIDLIST2.

In operation 705, the backup SMF1 sends a Session Set ModificationRequest to the UPF.

In the embodiment, the session Set Modification Request carries a nodeID of the backup SMF1, a node ID of the main SMF, and the CSIDLIST1taken over, and is used for notifying the UPF that the session orsessions in the CSIDLIST1 corresponding to the node identified by thenode ID is/are to be taken over by the backup SMF1.

In operation 706, the UPF identifies the failure of the main SMF, andrecords the correspondence between the failed SMF+CSIDLIST1 and thebackup SMF1.

In operation 707, the UPF sends a Session Set Modification Response tothe backup SMF1.

In operation 708, the backup SMF2 sends a Session Set ModificationRequest to the UPF. In the embodiment, the Session Set ModificationRequest carries the Node ID of the backup SMF2, the Node ID of the SMFand the CSIDLIST2 taken over, and is used for notifying the UPF that thesession or session in the CSIDLIST2 corresponding to the node identifiedby the Node ID is/are to be taken over by the backup SMF2.

In operation 709, the UPF identifies the failure of the main SMF, andrecords the correspondence between the failed SMF+CSIDLIST2 and thebackup SMF2.

In operation 710, the UPF sends a Session Set Modification Response tothe backup SMF2.

In operations 711-712, due to the usage report of the UPF or the triggerof the CP NF, the backup SMF1/backup SMF2 identifies that the session orsessions to be processed is/are a migrated session or migrated sessions,and acquires the context of the migrated session or sessions from theSMF tenant space of the UDSF.

In operation 713, the backup SMF1 sends a Session Modification Requestto the UPF to update the CP F-SEID, wherein the original session data inthe SEID part are kept unchanged, and the IP address is updated to theIP address of the backup SMF1.

In operation 714, after receiving the message, the UPF records the newCP F-SEID, and labels the session or sessions as migrated.

For the session or sessions set with a migration flag, when sending amessage or messages subsequently, the UPF needs to acquire the actualstate of the main SMF according to the correspondence between theSMF+CSIDLIST and the backup SMF1, and sends the message or messages ofthe session or sessions to the backup SMF1 in a case where the main SMFfails.

In operation 715, the UPF sends a Session Modification Response to thebackup SMF1.

In operations 716-718, the session update process of the backup SMF2 issimilar to the operations 713-715.

According to the technical solution provided in the fifth embodiment ofthe present disclosure, in a case where an SMF is down due to a failure,two backup SMFs, i.e., the backup SMF1 and the backup SMF2 take over twosession ranges CSIDLIST1 and CSIDLIST2 of the SMF, and notify, throughsending a PFCP Session Set Modification, the UPF to perform batchsession migration. Then, in a case where the backup SMF1 and/or thebackup SMF2 discovers that a session belongs to a migrated session, thebackup SMF1 and/or the backup SMF2 acquires the session context of theSMF from the UDSF, and notifies, by sending a PFCP Session Modificationmessage, the UPF to update session information including a CP F-SEID,and interact with the backup SMF for the subsequent session or sessions.In this way, the messages such as the PFCP Session Set ModificationRequest/PFCP Session Set Modification Response are extended to implementbatch session migration and ensure session continuity.

The embodiments of the present disclosure also provide a technicalsolution for implementing disaster recovery. By extending existingmessages, in a case where the main SMF recovers from a failure, a UPFcan identify that the failed SMF has recovered and migrate back originalsession information, thereby ensuring session continuity.

Sixth Embodiment

FIG. 8 is a schematic flowchart of a method for implementing disasterrecovery according to a sixth embodiment of the present disclosure. Asshown in FIG. 8, the method includes an operation 801.

In operation 801, in a case where a backup SMF has taken over a CSIDLISTcorresponding the backup SMF and a main SMF recovers from a failure, themain SMF sends a third request to a UPF.

In the embodiment, the third request carries a Node ID of the main SMF,a Node ID of a backup SMF, and a CSIDLIST corresponding to the main SMF.The third request is used for notifying the UPF that the main SMFrecovers from a failure and that a session or sessions in the CSIDLISTcorresponding to the main SMF is/are to be taken over by the main SMF,so that the UPF subsequently interacts with the main SMF for the sessionor sessions in the CSIDLIST corresponding to the main SMF.

Before the main SMF sends the third request to the UPF, the method mayfurther include the following operations.

The main SMF acquires the Node ID of the backup SMF and the CSIDLISTcorresponding to the main SMF from an NRF.

The main SMF acquires, through an UDSF, address information of the UPFthat has established at least one session with the backup SMF.

After the main SMF sends the third request to the UPF, the method mayfurther include the following operation.

The main SMF receives a third response to the third request from theUPF.

In some exemplary implementations of the embodiment, the third responseto the third request carries a Node ID of the main SMF. The thirdresponse to the third request is used for notifying the main SMF thatthe UPF accepts or rejects the third request.

After the main SMF sends the third request to the UPF or after the mainSMF receives the third response for accepting the third request sent bythe UPF, the method may further include the following operation.

The main SMF acquires context of the session or sessions in the CSIDLISTcorresponding to the main SMF from an UDSF.

After the main SMF acquires the context of the session or sessions inthe CSIDLIST corresponding to the main SMF from the UDSF, the method mayfurther include the following operation.

The main SMF sends a fourth request to the UPF.

In some exemplary implementations of the embodiment, the fourth requestcarries a CP F-SEID acquired from the context, an IP address in the CPF-SEID being updated to an IP address of the main SMF. The fourthrequest is used for notifying the UPF to record the updated CP F-SEIDfor the session or sessions in the CSIDLIST corresponding to the mainSMF, and remove a migration flag of the session or sessions in theCSIDLIST corresponding to the main SMF.

After the main SMF sends the fourth request to the UPF, the method mayfurther include the following operation.

The main SMF receives a fourth response to the fourth request from theUPF.

In some exemplary implementations of the embodiment, the fourth responseto the fourth request carries the Node ID of the main SMF. The fourthresponse to the fourth request is used for notifying the main SMF thatthe UPF accepts or rejects the fourth request.

In some exemplary implementations of the embodiment, in a case where thebackup SMF has taken over the CSIDLIST corresponding to the backup SMFand the main SMF recovers from the failure, the method may furtherinclude the following operation.

A notification message is sent to the backup SMF through an NRF. In someexemplary implementations of the embodiment, the notification message isused for notifying the backup SMF that the main SMF recovers from thefailure, so that the backup SMF, when receiving a message or messagesrelated to a session or sessions after the main SMF recovers from thefailure, redirects the received message or messages to the main SMF.

In some exemplary implementations of the embodiment, the third requestis an extended PFCP Session Set Modification Request.

In some exemplary implementations of the embodiment, the third responseto the third request is an extended PFCP Session Set ModificationResponse.

Seventh Embodiment

FIG. 9 is a schematic flowchart of a method for implementing disasterrecovery provided by a seventh embodiment of the present disclosure. Asshown in FIG. 9, the method includes operations 901 and 902.

In operation 901, a UPF receives a third request sent by a main SMF.

In the embodiment, the third request carries a Node ID of the main SMF,a Node ID of a backup SMF, and a CSIDLIST corresponding to the main SMF.The third request is used for notifying the UPF that the main SMFrecovers from a failure and a session or sessions in the CSIDLISTcorresponding to the main SMF is/are to be taken over by the main SMF.

In operation 902, the UPF sets a state of the main SMF in a storedcorrespondence table between the main SMF and the backup SMF to normalaccording to the third request, and subsequently interacts with the mainSMF for the session or sessions in the CSIDLIST corresponding to themain SMF.

In the embodiment, the correspondence table includes the state of themain SMF, the backup SMF corresponding to the main SMF, and the CSIDLISTcorresponding to the backup SMF.

After the main UPF receives the third request sent by the main SMF, themethod may further include the following operation.

The UPF sends a third response to the third request to the main SMF.

In some exemplary implementations of the embodiment, the third responseto the third request carries the Node ID of the main SMF. The thirdresponse to the third request is used for notifying the main SMF thatthe UPF accepts or rejects the third request.

In some exemplary implementations of the embodiment, in a case ofdetermining, according to a condition of the UPF, that the UPF iscapable of setting the state of the main SMF in the storedcorrespondence table between the main SMF and the backup SMF to normal,the UPF sends a third response for accepting the third request to theSMF.

In some exemplary implementations of the embodiment, in a case ofdetermining, according to the condition of the UPF, that the UPF is notcapable of setting the state of the main SMF in the storedcorrespondence table between the main SMF and the backup SMF to normal,the UPF sends the third response for rejecting the third request to theSMF.

In some exemplary implementations of the embodiment, after the UPF setsthe state of the main SMF in the stored correspondence table between themain SMF and the backup SMF to normal according to the third request, orafter the UPF sends the third response for accepting the third requestto the SMF, the method may further include the following operations.

The UPF receives a fourth request sent by the backup SMF.

In some exemplary implementations of the embodiment, the fourth requestcarries a CP F-SEID, an IP address in the CP F-SEID being updated to anIP address of the main SMF. The fourth request is used for notifying theUPF to record the updated CP F-SEID for the session or sessions in theCSIDLIST corresponding to the main SMF, and remove, from thecorrespondence table, a migration flag of the session or sessions in theCSIDLIST.

The UPF records the updated CP F-SEID for the session or sessions in theCSIDLIST corresponding to the main SMF according to the fourth request,and removes the migration flag of the session or sessions in theCSIDLIST from the correspondence table.

After the UPF receives the fourth request sent by the backup SMF, themethod may further include the following operation.

The UPF sends a fourth response to the fourth request to the main SMF.

In some exemplary implementations of the embodiment, the fourth responseto the fourth request carries the Node ID of the main SMF. The fourthresponse to the fourth request is used for notifying the main SMF thatthe UPF accepts or rejects the fourth request.

The technical solutions provided by the sixth embodiment and the seventhembodiment of the present disclosure are described in detail through twoexemplary embodiments.

Eighth Embodiment

The eighth embodiment of the present disclosure corresponds to ascenario in which the main SMF corresponds to one backup SMF and thebackup SMF has taken over the session range CSIDLIST of the main SMF inthe fourth embodiment.

FIG. 10 is a schematic flowchart of a method for implementing disasterrecovery provided by an eighth embodiment of the present disclosure. Asshown in FIG. 10, the method includes operations 1001 to 1009.

In operation 1001, a main SMF recovers from a failure.

In the embodiment, in a case where the main SMF fails, the backup SMFand the UPF have performed session migration, as described in the firstto seventh embodiments.

In operation 1002, after recovering from the failure, the main SMFacquires from the NRF the Node ID of the backup SMF and the CSIDLISTtaken over.

In the embodiment, the main SMF determines the session migration recordsand the rollback manner through the NRF, and acquires the CSIDLIST to betaken back according to the configuration information in the NRF.

After the main SMF recovers from the failure, the NRF notifies thebackup SMF that the main SMF has recovered, and the backup SMF stopsprocessing session information, and if session information is stillreceived, the backup SMF redirects the session information to the mainSMF.

In operation 1003, the main SMF sends a Session Set Modification Requestto the UPF.

In the embodiment, the main SMF may acquire, through the UDSF, theaddress information of the UPF that has established at least one sessionwith the backup SMF.

In the embodiment, the Session Set Modification Request carries the NodeID of the main SMF, the Node ID of the backup SMF, and the CSIDLIST. TheSession Set Modification Request is used for notifying the UPF that themain SMF recovers from the failure and that the session or sessions inthe CSIDLIST is/are to be taken over by the main SMF.

In operation 1004, the UPF identifies state recovery of the main SMF.

In the embodiment, the UPF sets the state of the main SMF to normal inthe correspondence table recording the mapping relation between the mainSMF+CSIDLIST and the backup SMF, and interacts with the main SMF for thesubsequent session or sessions. The correspondence table includes thestate of the main SMF, the backup SMF, and the CSIDLIST taken over.

In operation 1005, the UPF sends a Session Set Modification Response tothe main SMF.

In the embodiment, the Session Set Modification Response carries theNode ID of the main SMF and is used for notifying the main SMF that theUPF accepts the Session Set Modification Request.

Generally, in a case of determining, according to a condition of theUPF, that the UPF is able to set the state of the main SMF in the storedcorrespondence table to normal, the UPF sends a Session Set ModificationResponse indicating acceptance of the Session Set Modification Requestto the SMF. However, in a case of determining, according to thecondition of the UPF, that the UPF is not able to set the state of themain SMF in the stored correspondence table to normal, for example, in acase where the UPF is overloaded and cannot process the message, the UPFsends the Session Set Modification Response indicating rejection of theSession Set Modification Request to the SMF.

In operation 1006, the main SMF acquires context information of themigrated session or sessions from the UDSF.

In the embodiment, the SMF may acquire the context information of themigrated session or sessions from the SMF tenant space of the UDSF.

In operation 1007, the main SMF sends a Session Modification Request tothe UPF to update the CP F-SEID.

In the embodiment, the Session Modification Request is an existing PFCPinterface message and carries a CP F-SEID, and an IP address in the CPF-SEID is updated to an IP address of a main SMF. The SessionModification Request is used for notifying the UPF to record the updatedCP F-SEID for the session or sessions in the CSIDLIST, and remove themigration flag of the session or sessions in the CSIDLIST, wherein themigration flag is used for identifying that the corresponding session orsessions is/are a migrated session or migrated sessions.

In operation 1008, after receiving the message, the UPF records the newCP F-SEID, and removes the migration flag of the session or sessions.

In the embodiment, when sending a message subsequently, the UPF directlyinteracts with the main SMF without determining the correspondencebetween the SMF+CSIDLIST and the backup SMF.

In the embodiment, when the UPF receives the Session ModificationRequest, the operation 1008 can be directly performed in normal cases.However, if the UPF cannot process the Session Modification Request (forexample, a possible reason may be that the UPF is overloaded making itimpossible for the UPF to process the Session Set Modification Request),the UPF may directly send a Session Modification Response for rejectingthe request to the main SMF, and the update of the CP F-SEID fails.

In operation 1009, the UPF sends a Session Modification Response to theSMF.

The Session Modification Response is an existing PFCP interface message.The Session Modification Response carries a Node ID of the main SMF, andis used for notifying the main SMF that the UPF accepts the SessionModification Request.

According to the technical solution provided in the eighth embodiment ofthe present disclosure, after recovering from a failure, a main SMFsends a PFCP Session Set Modification to a UPF to perform batch sessionmigration, and the UPF identifies that a state of the main SMF recovers;then, the SMF notifies, by sending a PFCP Session Modification, the UPFto update the session information including CP F-SEID, and the UPFupdates the session information and removes the migration flag of thesession or sessions, and interacts with the main SMF for the subsequentsession or sessions. In this way, the messages such as the PFCP SessionSet Modification Request/PFCP Session Set Modification Response areextended to implement batch session migration and ensure sessioncontinuity.

Ninth Embodiment

The ninth embodiment of the present disclosure corresponds to a scenarioin which the main SMF corresponds to two backup SMFs and the backup SMF1and the backup SMF2 have taken over the session range CSIDLIST1 andCSIDLIST2 of the main SMF in the fifth embodiment.

FIG. 11 is a schematic flowchart of a method for implementing disasterrecovery according to a ninth embodiment of the present disclosure. Asshown in FIG. 11, the method includes operations 1101 to 1110.

In operation 1101, a main SMF recovers from a failure.

Before the present operation, the backup SMF1 and the backup SMF2 havetaken over the session ranges CSIDLIST1 and CSIDLIST2 of the failed SMF.

In operation 1102, after recovering from the failure, the main SMFdetermines, through the NRF, the session migration records and therollback manner, and acquires a CSIDLIST to be taken back according tothe configuration.

Meanwhile, the NRF notifies the backup SMF1 and the backup SMF2 that themain SMF has recovered. After receiving the notification, the BackupSMF1 and the backup SMF2 stop processing the session or sessions, andwhen receiving a session message, the backup SMF1 and the backup SMF2redirect the received session message to the main SMF.

After taking over the session ranges CSIDLIST1 and CSIDLIST2 of thefailed SMF, the backup SMF1 and the backup SMF2 also interact with theNRF to update the session information, and sets the session or sessionsthat can be migrated from the main SMF.

In operation 1103, the main SMF sends a Session Set Modification Requestto the UPF.

In the embodiment, the Session Set Modification Request carriesparameters such as a Node ID of the main SMF, a Node ID of the backupSMF1, a Node ID of the backup SMF2, the CSIDLIST1, and the CSIDLIST 2.The Session Set Modification Request serves as a takeover notification,and is used for notifying the UPF that the main SMF recovers from thefailure and that the session or sessions in the CSIDLIST1 and theCSIDLIST2 is/are to be taken over by the main SMF.

In operation 1104, the UPF identifies that the state of the main SMF isrecovered, and sets the state of the main SMF to normal in acorrespondence table for recording the correspondence between the mainSMF+CSIDLIST1/2 and the backup SMF1/backup SMF2.

The UPF interacts with the main SMF for the subsequent session orsessions.

When the UPF receives the Session Set Modification Request, theoperation 1104 may be directly performed in normal cases. However, ifthe UPF is not able to process the Session Set Modification Request (forexample, a possible reason may be that the UPF is overloaded making itimpossible for the UPF to process the Session Set Modification Request),the UPF may directly send a Session Set Modification Response forrejecting the request to the main SMF, and the session migration fails.

In operation 1105, the UPF sends a Session Set Modification Response tothe main SMF.

In the embodiment, the Session Set Modification Response carries theNode ID of the main SMF, and is used for notifying the main SMF that theUPF accepts the Session Set Modification Request.

In operation 1106, the main SMF acquires context information of themigrated session or sessions from the SMF tenant space of the UDSF.

In operation 1107, the SMF sends a Session Modification Request to theUPF to update the CP F-SEID.

In the embodiment, the Session Modification Request is an existing PFCPinterface message. The Session Modification Request carries a CP F-SEID,and an IP address in the CP F-SEID is updated to an IP address of a mainSMF, and is used for notifying the UPF to record the updated CP F-SEIDfor the session or sessions in the CSIDLIST, and remove the migrationflag of the session or sessions in the CSIDLIST.

In operation 1108, after receiving the message, the UPF records the newCP F-SEID, and removes the migration flag of the session or sessions.

In the embodiment, when sending a message subsequently, the UPF does notdetermine the correspondence between the SMF+CSIDLIST1/2 and the backupSMF1/backup SMF2, but directly interacts with the main SMF.

In the embodiment, when the UPF receives the Session ModificationRequest, the operation 1108 may be directly performed in normal cases.However, if the UPF is not able to process the Session ModificationRequest (for example, a possible reason may be that the UPF isoverloaded making it impossible for the UPF to process the Session SetModification Request), the UPF may directly send a Session ModificationResponse for rejecting the request to the main SMF, and the update ofthe CP F-SEID fails.

In operation 1109, the UPF sends a Session Modification Response to themain SMF.

In the embodiment, the Session Modification Response is an existing PFCPinterface message. The Session Modification Response carries the Node IDof the main SMF, and is used for notifying the main SMF that the UPFaccepts the Session Modification Request.

According to the technical solution provided in the ninth embodiment ofthe present disclosure, after recovering from a failure, a main SMFacquires, according to the configuration, a session or sessions (whichis/are defined as CSIDLIST1/2) needing to be taken back; then the SMFsends a PFCP Session Set Modification to the UPF to perform batchsession migration, and the UPF identifies that the state of the main SMFis recovered; then, the SMF notifies, by sending a PFCP SessionModification, the UPF to update session information including the CPF-SEID, the UPF updates the session information and removes themigration flag of the session or sessions, and interacts with the mainSMF for the subsequent session or sessions.

An embodiment of the present disclosure provides a backup SMF, as shownin FIG. 12, including:

a sending unit, configured to send a first request to a UPF in a casewhere a main SMF fails.

In the embodiment, the first request carries a Node ID of the main SMF,a Node ID of the backup SMF and a CSIDLIST corresponding to the backupSMF. The first request is used for notifying the UPF that the main SMFfails and a session or sessions in the CSIDLIST corresponding to thebackup SMF is/are to be taken over by the backup SMF, so that the UPFsubsequently interacts with the backup SMF for the session or sessionsin the CSIDLIST corresponding to the backup SMF.

The backup SMF may further include a receiving unit.

The receiving unit is configured to, after the backup SMF sends thefirst request to the UPF, receive a first response to the first requestfrom the UPF.

In some exemplary implementations of the embodiment, the first responseto the first request carries the Node ID of the backup SMF, and thefirst response to the first request is used for notifying the backup SMFthat the UPF accepts or rejects the first request.

In some exemplary implementations of the embodiment, the receiving unitis further configured to receive a notification message sent by an NRFbefore the backup SMF sends the first request message to the UPF.

In some exemplary implementations of the embodiment, the notificationmessage carries the Node ID of the main SMF, the Node ID of the backupSMF, and the CSIDLIST corresponding to the backup SMF. The notificationmessage is used for notifying the backup SMF that the main SMF fails andthe backup SMF takes over the session or sessions in the CSIDLISTcorresponding to the backup SMF.

The backup SMF may further include an acquiring unit.

The acquiring unit is configured to acquire, through an UDSF, addressinformation of the UPF currently having established at least one sessionwith the main SMF.

In some exemplary implementations of the embodiment, the acquiring unitis further configured to acquire from an UDSF a context of the sessionor sessions in the CSIDLIST corresponding to the backup SMF after thebackup SMF sends the first request to the UPF or after the backup SMFreceives the first response for accepting the first request from theUPF.

In some exemplary implementations of the embodiment, the sending unit isfurther configured to send a second request to the UPF after the backupSMF acquires from the UDSF the context of the session or sessions in theCSIDLIST corresponding to the backup SMF.

In some exemplary implementations of the embodiment, the second requestcarries a CP F-SEID acquired from the context, an IP address in the CPF-SEID being updated to an IP address of the backup SMF. The secondrequest is used for notifying the UPF to record the updated CP F-SEIDfor the session or sessions in the CSIDLIST, and set a migration flagfor the session or sessions in the CSIDLIST, wherein the migration flagis used for identifying the corresponding session or sessions asmigrated session or sessions.

The receiving unit is further configured to receive a second response tothe second request from the UPF after the backup SMF sends the secondrequest to the UPF. The second response to the second request carries aNode ID of the backup SMF, and the second response to the second requestis used for notifying the backup SMF that the UPF accepts or rejects thesecond request.

Before the receiving unit receives the notification message sent by theNRF, the main SMF has established at least one session with the UPF,registers a main-backup relation on the NRF, and sets the CSIDLISTcorresponding to the backup SMF.

In some exemplary implementations of the embodiment, the first requestis an extended Packet Forwarding Control Protocol node-type messageSession Set Modification Request (PFCP Session Set ModificationRequest).

In some exemplary implementations of the embodiment, the first responseto the first request is an extended Packet Forwarding Control Protocolnode-type message Session Set Modification Response (PFCP Session SetModification Response).

An embodiment of the present disclosure provides a UPF, as shown in FIG.13, including a receiving unit and a processing unit.

The receiving unit is configured to receive a first request sent by abackup SMF.

In the embodiment, the first request carries a Node ID of the main SMF,a Node ID of the backup SMF, and a CSIDLIST corresponding to the backupSMF. The first request is used for notifying the UPF that the main SMFfails and a session or sessions in the CSIDLIST corresponding to thebackup SMF is/are to be taken over by the backup SMF.

The processing unit is configured to record a correspondence tablebetween the main SMF and the backup SMF according to the first request,and subsequently interact with the backup SMF for the session orsessions in the CSIDLIST corresponding to the backup SMF. In theembodiment, the correspondence table includes a state of the main SMF,the backup SMF corresponding to the main SMF, and the CSIDLISTcorresponding to the backup SMF.

The UPF may further include a sending unit.

The sending unit is configured to send a first response to the firstrequest to a backup SMF after the UPF receives the first request sent bythe backup SMF.

In some exemplary implementations of the embodiment, the first responseto the first request carries the Node ID of the backup SMF. The firstresponse to the first request is used for notifying the backup SMF thatthe UPF accepts or rejects the first request.

In some exemplary implementations of the embodiment, in a case ofdetermining, according to a condition of the UPF, that the UPF iscapable of recording the correspondence table between the main SMF andthe backup SMF, the sending unit is configured to send the firstresponse for accepting the first request to the SMF.

In some exemplary implementations of the embodiment, in a case ofdetermining, according to the condition of the UPF, that the UPF is notcapable of recording the correspondence table between the main SMF andthe backup SMF, the sending unit is configured to send the firstresponse for rejecting the first request to the SMF.

In some exemplary implementations of the embodiment, the receiving unitis further configured to, after the UPF records the correspondence tablebetween the main SMF and the backup SMF according to the first request,or after the UPF sends the first response for accepting the firstrequest to the SMF, receive a second request sent by the backup SMF.

In some exemplary implementations of the embodiment, the second requestcarries a CP F-SEID, an IP address in the CP F-SEID being updated to anIP address of the backup SMF. The second request is used for notifyingthe UPF to record the updated CP F-SEID for the session or sessions inthe CSIDLIST corresponding to the backup SMF, and set a migration flagfor the session or sessions in the CSIDLIST corresponding to the backupSMF, wherein the migration flag is used for identifying thecorresponding session or sessions as migrated session or sessions.

The processing unit is further configured to record the updated CPF-SEID for the session or sessions in the CSIDLIST corresponding to thebackup SMF according to the second request, and set a migration flag forthe session or sessions in the CSIDLIST in the correspondence table.

In some exemplary implementations of the embodiment, the sending unit isfurther configured to send a second response to the second request tothe backup SMF after the UPF receives the second request sent by thebackup SMF.

In some exemplary implementations of the embodiment, the second responseto the second request carries the Node ID of the backup SMF. The secondresponse to the second request is used for notifying the backup SMF thatthe UPF accepts or rejects the second request.

In some exemplary implementations of the embodiment, the sending unit isfurther configured to, in a case where the UPF needs to send a messageor messages related to the session or sessions in the CSIDLISTcorresponding to the backup SMF, acquire the state of the main SMFaccording to the correspondence table; and

-   -   send the message or messages to the backup SMF in a case where        the state of the main SMF indicates that the main SMF fails.

An embodiment of the present disclosure provides a main SMF, as shown inFIG. 14, including:

a sending unit, configured to send a third request to a UPF in a casewhere a backup SMF has taken over a session or sessions in a CSIDLISTcorresponding to the backup SMF and a main SMF recovers from a failure.

In the embodiment, the third request carries a Node ID of the main SMF,a Node ID of the backup SMF, and a CSIDLIST corresponding to the mainSMF. The third request is used for notifying the UPF that the main SMFrecovers from a failure and that a session or sessions in the CSIDLISTcorresponding to the main SMF is/are to be taken over by the main SMF,so that the UPF subsequently interacts with the main SMF for the sessionor sessions in the CSIDLIST corresponding to the main SMF.

In some exemplary implementations of the embodiment, the main SMF mayfurther include an acquiring unit.

The acquiring unit is configured to acquire the Node ID of the backupSMF and the CSIDLIST corresponding to the main SMF from an NRF beforethe main SMF sends the third request to the UPF; and

acquiring, through a UDSF, address information of the UPF that hasestablished at least one session with the backup SMF.

In some exemplary implementations of the embodiment, the main SMFfurther includes a receiving unit.

The receiving unit is configured to, after the main SMF sends the thirdrequest to the UPF, receive a third response to the third request fromthe UPF.

In some exemplary implementations of the embodiment, the third responseto the third request carries a Node ID of the main SMF, and the thirdresponse to the third request is used for notifying the main SMF thatthe UPF accepts or rejects the third request.

In some exemplary implementations of the embodiment, the acquiring unitis further configured to, after the main SMF sends the third request tothe UPF or after the main SMF receives from the UPF the third responsefor accepting the third request, acquire from an UDSF a context of thesession or sessions in the CSIDLIST corresponding to the main SMF.

In some exemplary implementations of the embodiment, the sending unit isfurther configured to, after the main SMF acquires the context of thesession or sessions in the CSIDLIST corresponding to the main SMF fromthe UDSF, send a fourth request to the UPF.

In some exemplary implementations of the embodiment, the fourth requestcarries a CP F-SEID acquired from the context, an IP address in the CPF-SEID being updated to an IP address of the main SMF. The fourthrequest is used for notifying the UPF to record the updated CP F-SEIDfor the session or sessions in the CSIDLIST corresponding to the mainSMF, and remove a migration flag of the session or sessions in theCSIDLIST corresponding to the main SMF.

In some exemplary implementations of the embodiment, the receiving unitis further configured to, after the main SMF sends the fourth request tothe UPF, receive a fourth response to the fourth request from the UPF.

In some exemplary implementations of the embodiment, the fourth responseto the fourth request carries the Node ID of the main SMF, and thefourth response to the fourth request is used for notifying the main SMFthat the UPF accepts or rejects the fourth request.

In some exemplary implementations of the embodiment, the sending unit isfurther configured to, in a case where the backup SMF has taken over theCSIDLIST corresponding to the backup SMF and the main SMF has recoveredfrom the failure,

-   -   send a notification message to the backup SMF through an NRF,        wherein the notification message is used for notifying the        backup SMF that the main SMF recovers from the failure, so that        the backup SMF, when receiving a message or messages related to        the session or sessions after the main SMF recovers from the        failure, redirects the message or messages to the main SMF.

In some exemplary implementations of the embodiment, the third requestis an extended PFCP Session Set Modification Request.

In some exemplary implementations of the embodiment, the third responseto the third request is an extended PFCP Session Set ModificationResponse.

An embodiment of the present disclosure provides another UPF, as shownin FIG. 15, including a receiving unit and a processing unit.

The receiving unit is configured to receive a third request sent by amain SMF.

In the embodiment, the third request carries a Node ID of the main SMF,a Node ID of a backup SMF, and a CSIDLIST corresponding to the main SMF.The third request is used for notifying the UPF that the main SMFrecovers from a failure and a session or sessions in the CSIDLISTcorresponding to the main SMF is/are to be taken over by the main SMF.

The processing unit is configured to set a state of the main SMF in astored correspondence table between the main SMF and the backup SMF tonormal according to the third request, and to subsequently interact withthe main SMF for the session or sessions in the CSIDLIST correspondingto the main SMF. In the embodiment, the correspondence table includesthe state of the main SMF, the backup SMF corresponding to the main SMF,and the CSIDLIST corresponding to the backup SMF.

In some exemplary implementations of the embodiment, the UPF may furtherinclude a sending unit.

The sending unit is configured to send a third response to the thirdrequest to a main SMF after the main UPF receives the third request sentby the main SMF.

In some exemplary implementations of the embodiment, the third responseto the third request carries a Node ID of the main SMF, and the thirdresponse to the third request is used for notifying the main SMF thatthe UPF accepts or rejects the third request.

In some exemplary implementations of the embodiment, in a case ofdetermining, according to a condition of the UPF, that the UPF iscapable of setting the state of the main SMF in the storedcorrespondence table between the main SMF and the backup SMF to normal,the sending unit is configured to send the third response for acceptingthe third request to the SMF.

In some exemplary implementations of the embodiment, in a case ofdetermining, according to the condition of the UPF, that the UPF is notcapable of setting the state of the main SMF in the storedcorrespondence table between the main SMF and the backup SMF to normal,the sending unit is configured to send the third response for rejectingthe third request to the SMF.

In some exemplary implementations of the embodiment, the receiving unitis further configured to, after the UPF sets the state of the main SMFin the stored correspondence table between the main SMF and the backupSMF to normal according to the third request, or after the UPF sends thethird response for accepting the third request to the SMF, receive afourth request sent by the backup SMF.

In some exemplary implementations of the embodiment, the fourth requestcarries a CPF-SEID, an IP address in the CP F-SEID being updated to anIP address of the main SMF. The fourth request is used for notifying theUPF to record the updated CP F-SEID for the session or sessions in theCSIDLIST corresponding to the main SMF, and remove, from thecorrespondence table, a migration flag of the session or sessions in theCSIDLIST.

The processing unit is further configured to record the updated CPF-SEID for the session or sessions in the CSIDLIST corresponding to themain SMF according to the fourth request, and remove, from thecorrespondence table, the migration flag of the session or sessions inthe CSIDLIST.

The sending unit is further configured to, after the UPF receives thefourth request sent by the backup SMF, send a fourth response to thefourth request to the main SMF.

In some exemplary implementations of the embodiment, the fourth responseto the fourth request carries the Node ID of the main SMF, and thefourth response to the fourth request is used for notifying the main SMFthat the UPF accepts or rejects the fourth request.

An embodiment of the present disclosure provides a backup SMF, includinga memory, a processor, and a computer program stored in the memory andcapable of running on the processor. The computer program, when executedby the processor, performs any method for implementing disaster recoveryexecuted by the backup SMF.

An embodiment of the present disclosure provides a main SMF, including amemory, a processor and a computer program stored in the memory andcapable of running on the processor. The computer program, when executedby the processor, performs the method for implementing disaster recoveryexecuted by the main SMF.

An embodiment of the present disclosure provides a UPF, including amemory, a processor, and a computer program stored in the memory andcapable of running on the processor. The computer program, when executedby the processor, performs any one of the methods for implementingdisaster recovery executed by the UPF.

An embodiment of the present disclosure provides a computer readablestorage medium. The computer readable storage medium stores aninformation processing program, and when the information processingprogram is executed by a processor, the operations of any one of theforegoing methods for implementing disaster recovery are implemented.

Those having ordinary skill in the art can appreciate that all or someof the operations of the methods described above, and the functionalblocks/units in the systems and devices can be implemented as software,firmware, hardware, or any suitable combination thereof. In a hardwareimplementation, the division of the functional modules/units referred toin the above description does not necessarily correspond to the divisionof physical components. For example, one physical component may havemultiple functions, or one function or operation may be cooperativelyperformed by several physical components. Certain components orcomponents may be implemented as software executed by a processor, suchas a digital signal processor or microprocessor, or may be implementedas hardware, or as an integrated circuit, such as an applicationspecific integrated circuit. Such software may be distributed oncomputer-readable medium, which may include computer storage medium (ornon-transitory medium) and communication medium (or transitory medium).As is well known to those having ordinary skill in the art, the termcomputer storage medium includes volatile and non-volatile, removableand non-removable medium implemented in any method or technique forstoring information (such as computer readable instructions, datastructures, program modules, or other data). The computer storage mediumincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile discs (DVD) or otheroptical disk storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed by acomputer. In addition, the communication medium typically storescomputer readable instructions, data structures, program modules, orother data in a modulated data signal such as a carrier wave or othertransport mechanism and may include any information delivery medium asis known to those having ordinary skill in the art.

Although the embodiments disclosed in the present disclosure aredescribed above, the described contents are only the embodiments adoptedto facilitate understanding to the embodiments of the presentdisclosure, and are not intended to limit the present disclosure. Thosehaving ordinary skill in the art can make various modifications andvariations to the embodiments of the present disclosure withoutdeparting from the principle and scope of the embodiments of the presentdisclosure. The scope of the present disclosure is defined by theappended claims.

INDUSTRIAL APPLICABILITY

As described above, the methods and the related devices for implementingdisaster recovery provided by the embodiments of the present disclosurehave the following beneficial effects. In a case where a main SMF fails,a UPF is enabled to identify the failed SMF and acquire the backup SMFand the original session information, thereby implementing batch sessionmigration and ensuring session continuity.

1. A method for implementing disaster recovery, comprising: in a casewhere a main Session Management Function (SMF) fails, sending, by abackup SMF, a first request to a User Plane Function (UPF), wherein thefirst request carries a node identifier (Node ID) of the main SMF, aNode ID of the backup SMF and a Common Session endpoint Identifier List(CSIDLIST) corresponding to the backup SMF, and the first request isused for notifying the UPF that the main SMF fails and a session orsessions in the CSIDLIST corresponding to the backup SMF is/are to betaken over by the backup SMF, so that the UPF subsequently interactswith the backup SMF for the session or sessions in the CSIDLISTcorresponding to the backup SMF.
 2. The method according to claim 1,after sending, by the backup SMF, the first request to the UPF, furthercomprising: receiving, by the backup SMF, a first response to the firstrequest from the UPF, wherein the first response to the first requestcarries the Node ID of the backup SMF, and the first response to thefirst request is used for notifying the backup SMF that the UPF acceptsor rejects the first request.
 3. The method according to claim 1, beforesending, by the backup SMF, the first request to the UPF, furthercomprising: receiving, by the backup SMF, a notification message sent bya Network Function Repository Function (NRF), wherein the notificationmessage carries the Node ID of the main SMF, the Node ID of the backupSMF, and the CSIDLIST corresponding to the backup SMF, and thenotification message is used for notifying the backup SMF that the mainSMF fails and the backup SMF takes over the session or sessions in theCSIDLIST corresponding to the backup SMF; and acquiring, through anUnstructured Data Storage Function (UDSF) by the backup SMF, addressinformation of the UPF that has established at least one session withthe main SMF.
 4. The method according to claim 2, after sending, by thebackup SMF, the first request to the UPF or after receiving, by thebackup SMF, the first response for accepting the first request from theUPF, further comprising: acquiring, by the backup SMF, context of thesession or sessions in the CSIDLIST corresponding to the backup SMF froman Unstructured Data Storage Function (UDSF).
 5. The method according toclaim 4, after acquiring, by the backup SMF, the context of the sessionor sessions in the CSIDLIST corresponding to the backup SMF from theUDSF, further comprising: sending, by the backup SMF, a second requestto the UPF, wherein the second request carries a Control Plane (CP)Fully Qualified Session Endpoint Identifier (F-SEID) acquired from thecontext, an Internet Protocol (IP) address in the CP F-SEID beingupdated to an IP address of the backup SMF; and the second request isused for notifying the UPF to record the updated CP F-SEID for thesession or sessions in the CSIDLIST, and set a migration flag for thesession or sessions in the CSIDLIST, wherein the migration flag is usedfor identifying the corresponding session or sessions as migratedsession or sessions.
 6. (canceled)
 7. The method according to claim 3,before receiving, by the backup SMF, the notification message sent bythe NRF, further comprising: by the main SMF having established at leastone session with the UPF, registering a main-backup relation on the NRFand configuring the CSIDLIST corresponding to the backup SMF. 8.(canceled)
 9. A method for implementing disaster recovery, comprising:receiving, by a User Plane Function (UPF), a first request sent by abackup Session Management Function (SMF), wherein the first requestcarries a node identifier (Node ID) of a main SMF, a Node ID of thebackup SMF, and a Common Session endpoint Identifier List (CSIDLIST)corresponding to the backup SMF, and the first request is used fornotifying the UPF that the main SMF fails and a session or sessions inthe CSIDLIST corresponding to the backup SMF is/are to be taken over bythe backup SMF; and recording, by the UPF, a correspondence tablebetween the main SMF and the backup SMF according to the first request,and subsequently interacting, by the UPF, with the backup SMF for thesession or sessions in the CSIDLIST corresponding to the backup SMF,wherein the correspondence table comprises a state of the main SMF, thebackup SMF corresponding to the main SMF, and the CSIDLIST correspondingto the backup SMF, or, receiving, by the UPF, a third request sent by amain SMF, wherein the third request carries a Node ID of the main SMF, aNode ID of a backup SMF, and a CSIDLIST corresponding to the main SMF,and the third request is used for notifying the UPF that the main SMFrecovers from a failure and a session or sessions in the CSIDLISTcorresponding to the main SMF is/are to be taken over by the main SMF;and setting, by the UPF, a state of the main SMF in a correspondencetable between the main SMF and the backup SMF to normal according to thethird request, and subsequently interacting, by the UPF, with the mainSMF for the session or sessions in the CSIDLIST corresponding to themain SMF, wherein the correspondence table comprises the state of themain SMF, the backup SMF corresponding to the main SMF, and the CSIDLISTcorresponding to the backup SMF.
 10. The method according to claim 9,after receiving, by the UPF, the first request sent by the backup SMF,further comprising: sending, by the UPF, a first response to the firstrequest to the backup SMF, wherein the first response to the firstrequest carries the Node ID of the backup SMF, and the first response tothe first request is used for notifying the backup SMF that the UPFaccepts or rejects the first request; or, after receiving, by the UPF,the third request sent by the main SMF, further comprising: sending, bythe UPF, a third response to the third request to the main SMF, whereinthe third response to the third request carries the Node ID of the mainSMF, and the third response to the third request is used for notifyingthe main SMF that the UPF accepts or rejects the third request.
 11. Themethod according to claim 10, wherein in a case of determining,according to a condition of the UPF, that the UPF is capable ofrecording the correspondence table between the main SMF and the backupSMF, the UPF sends the first response for accepting the first request tothe SMF; and in a case of determining, according to the condition of theUPF, that the UPF is not capable of recording the correspondence tablebetween the main SMF and the backup SMF, the UPF sends the firstresponse for rejecting the first request to the SMF; or, in a case ofdetermining, according to a condition of the UPF, that the UPF iscapable of setting the state of the main SMF in the storedcorrespondence table between the main SMF and the backup SMF to normal,sending, by the UPF, the third response for accepting the third requestto the SMF; and in a case of determining, according to the condition ofthe UPF, that the UPF is not capable of setting the state of the mainSMF in the stored correspondence table between the main SMF and thebackup SMF to normal, sending, by the UPF, the third response forrejecting the third request to the SMF.
 12. The method according toclaim 910, after recording, by the UPF, the correspondence table betweenthe main SMF and the backup SMF according to the first request, or aftersending, by the UPF, the first response for accepting the first requestto the SMF, further comprising: receiving, by the UPF, a second requestsent by the backup SMF, wherein the second request carries a ControlPlane (CP) Fully Qualified Session Endpoint Identifier (F-SEID), anInternet Protocol (IP) address in the CP F-SEID being updated to an IPaddress of the backup SMF; and the second request is used for notifyingthe UPF to record the updated CP F-SEID for the session or sessions inthe CSIDLIST corresponding to the backup SMF, and set a migration flagfor the session or sessions in the CSIDLIST corresponding to the backupSMF, wherein the migration flag is used for identifying thecorresponding session or sessions as migrated session or sessions; andrecording, by the UPF, the updated CP F-SEID for the session or sessionsin the CSIDLIST corresponding to the backup SMF according to the secondrequest, and setting, in the correspondence table by the UPF, themigration flag for the session or sessions in the CSIDLIST; or, aftersetting, by the UPF, the state of the main SMF in the storedcorrespondence table between the main SMF and the backup SMF to normalaccording to the third request, or after sending, by the UPF, the thirdresponse for accepting the third request to the SMF, further comprising:receiving, by the UPF, a fourth request sent by the backup SMF, whereinthe fourth request carries a Control Plane (CP) Fully Qualified SessionEndpoint Identifier (F-SEID), an Internet Protocol (IP) address in theCP F-SEID being updated to an IP address of the main SMF; and the fourthrequest is used for notifying the UPF to record the updated CP F-SEIDfor the session or sessions in the CSIDLIST corresponding to the mainSMF, and remove, from the correspondence table, a migration flag of thesession or sessions in the CSIDLIST; and recording, by the UPF, theupdated CP F-SEID for the session or sessions in the CSIDLISTcorresponding to the main according to the fourth request, and removing,from the correspondence table by the UPF, the migration flag of thesession or sessions in the CSIDLIST.
 13. The method according to claim12, after receiving, by the UPF, the second request sent by the backupSMF, further comprising: sending, by the UPF, a second response to thesecond request to the backup SMF, wherein the second response to thesecond request carries the Node ID of the backup SMF, and the secondresponse to the second request is used for notifying the backup SMF thatthe UPF accepts or rejects the second request or, after receiving, bythe UPF, the fourth request sent by the backup SMF, further comprising:sending, by the UPF, a fourth response to the fourth request to the mainSMF, wherein the fourth response to the fourth request carries the NodeID of the main SMF, and the fourth response to the fourth request isused for notifying the main SMF that the UPF accepts or rejects thefourth request.
 14. (canceled)
 15. A method for implementing disasterrecovery, comprising: in a case where a backup Session ManagementFunction (SMF) has taken over a session or sessions in a Common Sessionendpoint Identifier List (CSIDLIST) corresponding to the backup SMF anda main SMF recovers from a failure, sending, by the main SMF, a thirdrequest to a User Plane Function (UPF), wherein the third requestcarries a node identifier (Node ID) of the main SMF, a Node ID of thebackup SMF, and a CSIDLIST corresponding to the main SMF, and the thirdrequest is used for notifying the UPF that the main SMF recovers fromthe failure and that a session or sessions in the CSIDLIST correspondingto the main SMF is/are to be taken over by the main SMF, so that the UPFsubsequently interacts with the main SMF for the session or sessions inthe CSIDLIST corresponding to the main SMF.
 16. The method according toclaim 15, before sending, by the main SMF, the third request to the UPF,further comprising: acquiring, from a Network Function RepositoryFunction (NRF) by the main SMF, the Node ID of the backup SMF and theCSIDLIST corresponding to the main SMF; and acquiring, through anUnstructured Data Storage Function (UDSF) by the main SMF, addressinformation of the UPF that has established at least one session withthe backup SMF.
 17. The method according to claim 15, after sending, bythe main SMF, the third request to the UPF, further comprising:receiving a third response to the third request from the UPF, whereinthe third response to the third request carries the Node ID of the mainSMF, and the third response to the third request is used for notifyingthe main SMF that the UPF accepts or rejects the third request.
 18. Themethod according to claim 17, after sending, by the main SMF, the thirdrequest to the UPF or after receiving, by the main SMF, the thirdresponse for accepting the third request from the UPF, furthercomprising: acquiring, from an Unstructured Data Storage Function (UDSF)by the main SMF, context of the session or sessions in the CSIDLISTcorresponding to the main SMF; and sending, by the main SMF, a fourthrequest to the UPF, wherein the fourth request carries a Control Plane(CP) Fully Qualified Session Endpoint Identifier (F-SEID) acquired fromthe context, an Internet Protocol (IP) address in the CP F-SEID beingupdated to an IP address of the main SMF; and the fourth request is usedfor notifying the UPF to record the updated CP F-SEID for the session orsessions in the CSIDLIST corresponding to the main SMF, and remove amigration flag of the session or sessions in the CSIDLIST correspondingto the main SMF.
 19. (canceled)
 20. The method according to claim 1918,after sending, by the main SMF, the fourth request to the UPF, furthercomprising: receiving, by the main SMF, a fourth response to the fourthrequest from the UPF, wherein the fourth response to the fourth requestcarries the Node ID of the main SMF, and the fourth response to thefourth request is used for notifying the main SMF that the UPF acceptsor rejects the fourth request.
 21. The method according to claim 15, ina case where the backup SMF has taken over the session or sessions inthe CSIDLIST corresponding to the backup SMF and the main SMF recoversfrom the failure, further comprising: sending a notification message tothe backup SMF through a Network Function Repository Function (NRF),wherein the notification message is used for notifying the backup SMFthat the main SMF recovers from the failure, so that the backup SMF,when receiving a message or messages related to a session or sessionsafter the main SMF recovers from the failure, redirects the receivedmessage or messages to the main SMF. 22.-31. (canceled)
 32. A backupSession Management Function (SMF), comprising a memory, a processor anda computer program stored in the memory and capable of running on theprocessor, wherein the computer program, when executed by the processor,performs the method for implementing the disaster recovery according toclaim
 1. 33. A main Session Management Function (SMF), comprising amemory, a processor and a computer program stored in the memory andcapable of running on the processor, wherein the computer program, whenexecuted by the processor, performs the method for implementing thedisaster recovery according to claim
 15. 34. A User Plane Function(UPF), comprising a memory, a processor and a computer program stored inthe memory and capable of running on the processor, wherein the computerprogram, when executed by the processor, performs the method forimplementing the disaster recovery according to claim
 9. 35. (canceled)36. (canceled)